chore: release v0.9.15 - #7202

Reviewed at 728f251220cf44a073cfbcef208797c14fd5ab09.

The release increment is clean: 19 manifests change only version from 0.9.14 to 0.9.15; all publishable workspace packages agree. The other two changed files are the release notes and changelog entry. No new finding.

git log v0.9.14..HEAD^ contains exactly aace91b5e (#6983) and f6ae9bfb4 (#7199), both represented in the notes. GitHub confirms #7199 merged as f6ae9bfb43a4e4bee0d132a5ac2a0b1ce4bf383f, this release's direct parent. The audio wording correctly scopes the loudness fix to FFmpeg 4; this release audit does not repeat the implementation review.

.github/workflows/publish.yml:11 handles merged PRs into main from release/v*, checks out the immutable merge SHA, creates the stable tag and publishes. This branch is release/v0.9.15. The push trigger accepts prerelease tags only (v*-*); a stable tag push alone publishes nothing.

Validation: node scripts/ci/release-only-diff.mjs --base f6ae9bfb43a4e4bee0d132a5ac2a0b1ce4bf383f --verify reports release only: 21 files, versions and notes. Independent JSON/range assertions passed for all 19 manifests and both commits. The release-only and channel-validator suites passed 18 tests; the separate publish-workflow test could not load because this fresh checkout lacks the yaml dependency. I inspected that unchanged workflow directly. No package build, publish, or full render rerun.

Audited: every changed manifest via full JSON comparison, both new note entries, exact commit range, release preparation/version helpers and publish/channel workflow. Trusting: the separately landed feature implementations and their prior review evidence.

Need: yes, ship the two landed changes · Size: ok · Reuse: existing release:prepare and publish workflow · Simpler: already minimal · Structure: fine
Risk: low — mechanical release metadata; publishing uses the established merged release-PR path.

Verdict: APPROVE
Reasoning: The package versions, release range and notes agree, and the branch follows the stable publishing contract.

— Rames / hf-review

Approved the release metadata at 728f2512. All 19 manifests increment only 0.9.14 → 0.9.15; the other two files are the matching notes/changelog. The exact v0.9.14…f6ae9bf range has only #6983 and #7199, and the FFmpeg-4 qualification matches the landed audio fix. Rames independently approved the same head. CI is still pending; publishing and merging remain with the release owner. — Jerrai

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head 728f2512

• blocker — #7194 ships with no notes. fix(cli): a browser install goes on when Windows holds a file for a moment (2372fc3) merged to main at 02:08Z, after this branch was cut at f6ae9bf. publish.yml tags this PR's merge commit, and the queue squashes it onto current main. So v0.9.15 will include the Windows EBUSY/EPERM/EACCES retry for hyperframes browser ensure, but neither releases/v0.9.15.md nor the docs/changelog.mdx block mentions it. To fix: rebase onto main, rerun release:prepare 0.9.15 (or scripts/draft-changelog.ts 0.9.15 --from v0.9.14 --to origin/main), and add a CLI: Fixes bullet to both files. Add "CLI" to the <Update> tags too.

Withdrawing my earlier approval at this same head: the release's moving main has acquired two commits after its f6ae9bf cut, so the merge-queue result would publish code absent from the v0.9.15 notes. I independently verified main now includes #7194 (2372fc34, Windows browser-install retry, merged 02:08Z) and #7195 (e2a65358, paused preview cleanup, merged 02:10Z). Neither appears in either notes file. Rebase/update the release branch onto current main and regenerate/update both releases/v0.9.15.md and docs/changelog.mdx for the actual release range, adding CLI/Core tags as appropriate; recheck the range again immediately before merge. My former approval covered only the frozen v0.9.14…f6ae9bf range and cannot clear the newly composed release. — Jerrai